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(54) An elctronic bill presentment technique with enhanced biller control 



(57) An electronic bill presentment system includes 
a network, a central network station, and a plurality of 
user and biller network stations. Each of the user sta- 
tions is associated with a respective one of a plurality of 
users and is operable to transmit first requests for bills 
via the network. The central network station receives the 
transmitted first requests and transmits, responsive 



thereto, bill availability infomriation via the network. The 
user stations receive the transmitted bill availability in- 
formation and are operable to transnriit second requests 
for bills via the network. Each of the biller stations is as- 
sociated with a respective one of the plurality of billers. 
The biller stations receive the transmitted second re- 
quests and transmit, responsive thereto, the requested 
bills via the network. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to dis- 
tributed data networks and, more particularly, to a dis- 
tributed data accessing technique. 

BACKGROUND OF THE INVENTION 

[0002] There are two prevalent models for electronic 
bill presentment that are currently used in industry. The 
first Is an aggregation model 10, which is shown in Fig- 
ure 1 . In Its simplest fomri, the aggregation model 1 0 in- 
cludes a customer 12, an aggregator 14, and a plurality 
of billers 16. The customer 12 can be, for example, an 
Individual person, a family, or a business. The aggrega- 
tor 14 can be a financial institution (Fl) such as, for ex- 
ample, a bank. Alternatively, the aggregator 14 can be 
a separate entity which acts of behalf of a sponsor 18, 
which can also be an Fl such as a bank. Each biller 16 
can be of any billing institution type such as, for exam- 
ple, a local telephone company, a local electric compa- 
ny, a retail outlet, or a national long distance telephone 
company. 

[0003] Each biller 16 provides customer-related in- 
voice data to the aggregator 14. The aggregator 14 
serves as an intemnediary between each biller 16 and 
the customer 12 by providing bill presentment directly 
to the customer 12. 

[0004] There are two variants of the aggregation mod- 
el 1 0 resulting from the ownership, or "branding", of the 
presentation experience and the communication chan- 
nel between the aggregator 1 4 and the customer 12. In 
one variant, the aggregator 14 may offer aggregator- 
branding, thus totally owning both the presentation ex- 
perience and the communication channel between the 
aggregator 1 4 and the customer 1 2 . 1 n the other variant, 
the aggregator 14 may offer sponsor-branding, thus 
staying "behind the scenes" in terms of the presentation 
experience and supporting the communication channel 
between the aggregator 14 and the customer 12. 
[0005] The second prevalent model for electronic bill 
presentment is a biller direct model 20, which is shown 
in Figure 2. In its simplest form, the biller direct model 
20 includes a customer 12 and at least one biller 16. In 
the biller direct model 20, each biller 16 retains the cus- 
tomer-related invoice data and the full relationship with 
the customer 12, i.e., the presentation experience and 
the communication channel. The customer 1 2 may have 
software for providing a capability similar to Web brows- 
er bookmarking so as to allow easy navigation between 
billers, and thus some level of virtual aggregation. How- 
ever, there is no actual aggregation such as with the ag- 
gregator 14 of the aggregation model 10 described 
above. 

[0006] The above-described models present a dichot- 
omy between a sponsor-centric view and a biller-centric 



view of bill presentment. That is, the aggregation model 
10 allows the aggregator 14 and/or the sponsor 18 to 
use customer-related invoice data, bill presentment, 
and the communication channel between the aggrega- 

5 tor 1 4 and the customer 1 2 for cross-selling or other pe- 
ripheral services. The biller direct model 20, on the other 
hand, insures that control of customer-related invoice 
data, bill presentment, and the communication channel 
between the biller 1 6 and the customer 1 2 remains with 

10 the biller 16. 

[0007] Also, neither of the above-described models 
adopt a truly customer-centric view. That is, neither of. 
the above-described models allow a customer 12 to in- 
teract directly with Individual billers 16 while retaining 

15 the benefits of interacting with a single aggregator 14, 
such as the ability to retain a single authentication and 
log-in procedure and a common bill presentation frame- 
work. Further, neitherofthe above-described models al- 
low a customer 12 to retain the benefits of interacting 

20 with a single aggregator 14 white allowing the aggrega- 
tor 14, billers 16, and sponsor 18 to retain certain pref- 
erences, such as the ability to retain control of customer- 
related data and a communication channel with each 
customer 12. Accordingly, it would be desirable to pro- 

25 vide a distributed data accessing technique which ad- 
dresses the above-mentioned shortcomings of the 
above-described models. 

OBJECTS OF THE INVENTION 

30 

[0008] One object of the present invention is to pro- 
vide a distributed data accessing technique that allows 
acustomerto interact directly with individual billers while 
retaining the benefits of interacting with a single aggre- 
35 gator. 

[0009] Another object of the present invention is to 
provide a distributed data accessing technique that al- 
lows a customer to retain the benefits of interacting with 
a single aggregator while allowing the aggregator, bill- 
40 ers, and sponsor to retain control of customer-related 
data and a communication channel with each customer. 
[0010] Another object of the present invention is to 
provide a distributed data accessing technique that al- 
lows complete flexibility as to who is offering bill present- 
's ment: billers only, aggregator only, or some combination 
of the above. 

[0011] Another object of the present invention is to 
provide a distributed data accessing technique that sup- 
ports an audit trail which can serve any of a variety of 

50 purposes, including improved customer care. 

[001 2] The above-stated objects, as well as other ob- 
jects, features, and advantages, of the present invention 
will become readily apparent from the following detailed 
description which is to be read in conjunction with the 

55 appended drawings. 
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SUMMARY OF THE INVENTION 

[0013] According to the present invention, a distribut- 
ed data accessing technique is realized by storing, at a 
first network station, Information identifying data which 
is available at a second network station. The first net- 
work station can be, for exannple, an electronic payment 
and customer service entity. The second network station 
can be, for example, a billing entity such as a utility com- 
pany. The infomriation identifying the data that Is avail- 
able at the second network station can be, for example, 
information which Indicates that a bill is available at the 
second network station. 

[0014] A signal is generated at the first network sta- 
tion. The signal represents the information identifying 
the available data at, and linking infomnation to, the sec- 
ond network station. The linking infomnation can be, for 
example, a web site address along with some additional 
parameters. 

[0015] The signal is transmitted to a third networksta- 
tion. The third network station can be, for example, a 
user entity such as a personal computer. The transmit- 
ted linking information Is operable at the third network 
station to establish a network link over which the iden- 
tified available data is transmittable from the second net- 
work station to the third network station. That is, the third 
network station can invoke the linking information so as 
to create, for example, a link to the web site of a billing 
entity. 

[0016] The signal is typically generated in response 
to a request for data. Such a request can include an 
identification of a user so that the user can be authenti- 
cated. The signal is then generated after the user is au- 
thenticated. The request is typically received from the 
third network station. The request, as well as any other 
events that occur between the various network stations, 
can be logged at the first network station. The logged 
events can then be accessed by another entity, such as, 
a centralized customer service center, which could be a 
fourth network station. 

[001 7] The identified available data Is typically stored 
at the second network station. This data could, if de- 
sired, be provided to the second network station by an 
entity located outside of the network, such as a legacy 
billing system or an established billing aggregator 
[0018] Accordingtootheraspects of the invention, the 
first network station receives a notification that the iden- 
tified available data was transmitted from the second 
network station to the third network station. The identi- 
fied available data is preferably transmitted from the 
second network station directly to the third network sta- 
tion over the network link established between the sec- 
ond and third network stations as discussed above. The 
Identified available data can then be transmitted from 
the second network station to the third network station 
so as to be displayed in a presentation format. The pres- 
entation format can be, for example, an intemet web 
page or a frame of an Internet web page. 



[0019] Preferably, only a single authentication proce- 
dure Is required for a user entity to receive available data 
identifying infomnation and linking Infonmation for differ- 
ent data available a different sites, e.g. different bills at 
5 different biller sites. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] In order to facilitate a fuller understanding of 
10 the present invention, reference is now made to the ap- 
pended drawings. These drawings should not be con- 
strued as limiting the present invention, but are intended 
to be exemplary only. 

[0021 ] Figure 1 is an aggregation model for electronic 
15 bill presentment. 

[0022] Figure 2 is a biller direct model for electronic 
bill presentment. 

[0023] Figure 3 is an infrastructure diagram of a dis- 
tributed database entity in accordance with the present 
20 invention. 

[0024] Figure 4 is a schematic diagram of an electron- 
ic bill presentment and payment system in accordance 
with the present invention. 

[0025] Figure 5 Is a schematic diagram of an electron- 
25 ic payment and customer service (EPCS) entity In ac- 
cordance with the present invention. 
[0026] Figure 6 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown In 
Figure 4, extended to include certain associated directly 
30 related systems, 

[0027] Figure 7 Is a schematic diagram of the elec- 
tronic bill presentment and payment system shown In 
Figure 4, extended to Include certain associated indi- 
rectly related systems. 
35 [0028] Figure 8 is a schematic diagram of the elec- 
tronic bill presentment and payment system shown In 
Figure 4, extended to include certain associated cus- 
tomer care entities. 

[0029] Figure 9 is a schematic diagram of the elec- 
40 tronic bill presentment and payment system shown In 
Figure 4, extended to include a centralized customer 
care entity. 

[0030] Figure 10 is a flowchart diagram showing Initial 
sign-on data and message flows between a user entity 

45 and a banking entity in the electronic bill presentment 
and payment system shown in Figure 4. 
[0031 ] Figure 11 is a flowchart diagram showing sign- 
on and authentication data and message flows between 
a user entity, a banking entity, and an EPCS entity in the 

50 electronic bill presentment and payment system shown 
in Figure 4. 

[0032] Figure 12 is a flowchart diagram showing bill 
availability data and message flows between a user en- 
tity, a banking entity, and an EPCS entity in the electron- 
55 ic bill presentment and payment system shown In Figure 
4. 

[0033] Figure 1 3A is a flowchart diagram showing bill- 
ing entity presentment data and message flows be- 



3 



5 



EP1 136 922 A1 



6 



tween a user entity, a billing entity, and an EPCS entity 
in the electronic bill presentment and payment system 
shown in Figure 4. 

[0034] Figure 1 3B is a flowchart diagram showing bill- 
ing aggregator bill presentment data and message flows 
between a user entity, a billing entity, an EPCS entity, 
and an established billing aggregator in the electronic 
bill presentment and payment system shown in Figure4. 
[0035] Figure 1 3C is a flowchart diagram showing al- 
ternative system bill presentment data and message 
flows between a user entity, an EPCS entity, and an al- 
ternative bill presentment and payment system in the 
electronic bill presentment and payment system shown 
in Figure 4. 

[0036] Figure 14 is a flowchart diagram showing bill 
payment data and message flows between a user entity, 
an EPCS entity, and a billing entity in the electronic bill 
presentment and payment system shown in Figure 4. 
[0037] Figure 15 is a flowchart diagram showing bill 
remittance and debiting data and message flows be- 
tween an EPCS entity and a billing entity and a banking 
entity in the electronic bill presentment and payment 
system shown In Figure 4. 

[0038] Figure 1 6 shows an example of a branded in- 
terface having a sign-on request prompt that includes a 
username field and a password field. 
[0039] Figure 1 7 shows an example of a banking en- 
tity home page, including a "view bills" icon, a "view 
checking account" icon, and a "view savings account" 
icon. 

[0040] Figure 1 8 shows a first modified banking entity 
home page having a frame presenting new bill availa- 
bility data. 

[0041] Figure 19 shows a second modified banking 
entity home page having a frame presenting detailed bill 
data. 

[0042] Figure 20 is a flowchart diagram showing cus- 
tomer service data and message flows between a cen- 
tralized customer service center, and an EPCS entity, a 
billing entity, and a banking entity in the electronic bill 
presentment and payment system shown in Figure 4. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

[0043] Referring to Figure 3, there is shown an infra- 
structure diagram of a distributed database entity 30 in 
accordance with the present invention. The distributed 
database entity 30 comprises a database component 32 
and a plurality of message interfaces 34-40 for facilitat- 
ing communication between the database component 
32 and other distributed database entities and system 
components. The database component 32 typically con- 
tains data that is controlled or "owned" by the controller 
or "owner" of the distributed database entity 30. For ex- 
ample, If the distributed database entity 30 is owned by 
a financial institution (Fl) such as a bank, then the da- 
tabase component 32 could contain infomnation such as 



checking and savings account balances. It should be 
noted, however, that the database component 32 can 
also contain data from other distributed database enti- 
tles and system components, as will be described in de- 

5 tail below. 

[0044] The plurality of message interfaces 34-40 in- 
cludes an internal message interface 34, an external 
message interface 36, a partner message interface 38, 
and a customer care message interface 40. 

10 [0045] The internal message Interface 34 defines 
messages that are used to communicate and query data 
between the distributed database entity 30 and othe.r. 
distributed database entities, or other system compo- 
nents having an internal message interface. For exam- 

15 pie, in a bill presentment and payment system, commu- 
nication between a banking entity and a billing entity 
may be required. 

[0046] The external message interface 36 defines 
messages that are used to communicate and query data 
20 between the given distributed database entity 30 and 
any existing system(s) that are directly related to the dis- 
tributed database entity 30. For example, an Fl such as 
a bank can have an existing direct deposit account 
(DDA) system. 

25 [0047] The partner message interface 38 defines 
messages that are used to communicate and query data 
between the distributed database entity 30 and any ex- 
isting system(s) that are indirectly related to the given 
distributed database entity 30. For example, in a bill pre- 

30 sentment and payment system, communication with an 
established billing aggregator may be necessary to sat- 
isfy customer demands. 

[0048] The customer care message interface 40 de- 
fines messages that are used to communicate and que- 

55 ry data between the given distributed database entity 30 
and a customer care entity. For example, in a bill pre- 
sentment and payment system, a billing entity may allow 
a third party to access bill data in order to provide feed- 
back to bill customers. 

40 [0049] It should be noted that all of the above-de- 
scribed interfaces will be described in greater detail be- 
low. 

[0050] Referring to Figure 4, there is shown a sche- 
matic diagram of a versatile electronic bill presentment 

45 and payment system 50 in accordance with the present 
invention. The system 50 includes a user entity 52, a 
banking entity 54, a billing entity 56, and an electronic 
payment and customer service (EPCS) entity 58. For 
purposes of this detailed description, each of entities 52, 

50 54, 56 and 58 is similar to the distributed database entity 
30, as described above, but could, if desired, have only 
an internal message interface 34 so that communica- 
tions can take place between each entity. 
[0051] It should be noted that, although only a single 

55 user entity 52, banking entity 54, billing entity 56, and 
EPCS entity 58 are shown in the system 50, a plurality 
of each of these entities may exist in an actual versatile 
electronic bill presentment and payment system in ac- 
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cordance with the present invention. Since the entities 
52, 54, 56 and 58 are all distributed database entities, 
they all connmunicate through internal message inter- 
faces 34, These communications are performed over in- 
terconnections 60, which can be wire, optical fiber, or 
wireless interconnections. 

[0052] Each internal message interface 34, external 
message interface 36, partner message interface 38. 
and customer care message interface 40, can be imple- 
mented using any number of existing message-based 
communication systems such as, for example, a TCP/ 
IP message-based communication system running on 
the infrastructure of the internet. Alternatively, the inter- 
faces 34, 36, 38 and 40 could be implemented using 
proprietary messaging software on a private network or 
intranet. It should also be noted that there are no re- 
quirements as to the nature of the messaging protocol, 
or any middleware used to support the messaging. 

THE USER ENTITY 

[0053] The user entity 52 is typically a personal com- 
puter (PC) that is directly connected to the system 50, 
or is connected to the system 50 through a network serv- 
er (not shown). Thus, the database component 32 as- 
sociated with the user entity 52 can be located on the 
PC, e.g., atraditional "fat" client, or on the network serv- 
er, e.g., an HTML browser client. It should be noted that 
the database component 32 associated with the user 
entity 52 could, if desired, also be located in one or dis- 
tributed among all of the other distributed database en- 
tities, which can download data to the user entity 52, e. 
g., a Java client. Thus, each database component 32 
should not be thought of as a single, monolithic data- 
base. Rather, each database component 32 is better de- 
scribed as a distributed repository of data categorized 
by the entity that "owns" the data. 
[0054] Wherever it is located, the database compo- 
nent 32 associated with the user entity 52 stores data 
that is related to the type of user interface (Ul) that is 
being presented to a subscriber of the system 50. For 
example, the database component 32 associated with 
the user entity 52 can store data that is related to the 
particular type of presentation technology being used, 
e.g., a "fat" client, an HTML browser client, or a Java 
client, a specific application, or a particular version of an 
application. The database component 32 associated 
with the user entity 52 can also store data that is related 
to a particular computing session, such as the existence 
of a computing session and/or the duration of a comput- 
ing session, and subscriber authentication data, which 
is described in detail below. 

[0055] The main function of the user entity 52 is to 
build a Ul using data obtained from the other distributed 
database entities, and then present the U I to a subscrib- 
er of the system 50. The presentation of the Ul to a sub- 
scriber is dependent upon the particular type of presen- 
tation technology being used, e.g., a "fat" client, an 



HTML browser client, or a Java client. For example, a 
Ul for a Java client requires that presentation data be 
downloaded from one of the other distributed database 
entities. 

5 [0056] Other functions of the user entity 52 Include 
storing certain data locally so as to facilitate off-line ed- 
iting and viewing, maintaining a state in a connection- 
less environment, e.g., an HTTP environment, and 
sensing the availability of software updates and manag- 

10 ing their subsequent application. All of these functions 
depend on the nature of the client, e.g., a "faf client, an 
HTML browser client, or a Java client. Another function 
of the user entity 52 is storing subscriber authentication 
data, e.g., a security ticket that is used to gain access 

15 to other distributed database entities in the system 50. 

THE BANKING ENTITY 

[0057] The banking entity 54, which is typically an Fl, 

20 such as a bank, is generally viewed as a primary point 
of contact for a subscriber to the system 50, typically 
providing an appearance of aggregation to the subscrib- 
er This is primarily due to the trust that consumers typ- 
ically place in a bank brand, and the fact that bank cus- 

25 tomers who already bank online are also likely to want 
to receive bills online. Thus, in the following discussion, 
the banking entity 54 is assumed to be the aggregator 
of the system 50. It should be noted, however, that any 
one of the other entities could also be the aggregator of 

30 the system 50 in accordance with the present invention. 
There are several factors which can be used to deter- 
mine aggregator status such as market clout. 
[0058] The banking entity 54 typically gains access to 
the system 50 through a network server (not shown). 

35 Thus, the database component 32 associated with the 
banking entity 54 can be located in the network server, 
but could also be located in a system associated with 
the banking entity 54, such as a DDA system. Such a 
DDA system could be accessed through the external 

40 message interface 36 of the banking entity 54, as de- 
scribed in detail below. The database component 32 as- 
sociated with the banking entity 54 could, if desired, also 
be located in one, or be distributed among all, of the 
other distributed database entities. 

45 [0059] Wherever it is located, the database compo- 
nent 32 associated with the banking entity 54 stores 
bank-specific subscriber profile data profile such as, for 
example, subscriber names and addresses and sub- 
scriber account numbers. The database component 32 

50 can also store account infonnatton, such as static ac- 
count information, e.g., lease rate, principle, and dy- 
namic account information, e.g. , balance, and profile da- 
ta specifically associated with the Fl, such as graphics, 
business rules, banking-related transaction histories, 

55 and aggregation relationships, e.g. those between the 
Fl and billers. 

[0060] Since it is likely that the system 50 will be used 
with existing banking systems, such as an existing DDA 
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system, one of the main functions of the banking entity 
54 is the continuation of current banking and bill pay- 
ment functionality, including maintaining customer pro- 
files and already existing interfaces. In its role as aggre- 
gator, the banking entity 54 also provides data to the 
user entity 52 to be used for the creation of a navigation 
portion of a Ul. For an HTML browser client, this data 
would be used to create a navigation frame, but not a 
content specific frame. The banking entity 54 can also 
provide data to the user entity 52 to be used for the cre- 
ation of a Ul for traditional banking and bill payment. 
[0061 ] Since the banking entity 54 is generally viewed 
as the primary point of contact for a subscriber to the 
system 50, the banking entity 54 also functions as the 
likely, but not exclusive, entry point for subscriber sign- 
on. Thus, the banking entity 54 typically controls the 
sign-on and authentication procedures for subscribers 
using the user entity 52. It should be noted that the bank- 
ing entity 54 typically works In conjunction with the 
EPCS entity 58 in controlling the authentication proce- 
dure, as described in detail below, 
[0062] Another function of the banking entity 54 In- 
cludes tracking bank related events and storing them in 
an event tracking database, which is typically associat- 
ed with the EPCS entity 58, as will also be described in 
detail below. 

THE BILLING ENTITY 

[0063] The billing entity 56 is commonly a biller such 
as, for example, a utility company. The billing entity 56 
typically gains access to the system 50 through a net- 
work server (not shown). Thus, the database compo- 
nent 32 associated with the billing entity 56 can be lo- 
cated In the network server However, if desired, the da- 
tabase component could also be located in a system as- 
sociated with the billing entity 56, such as a legacy billing 
system, or in one or among all of the other distributed 
database entities. Such a legacy billing system could be 
accessed through the external message interface 36 of 
the billing entity 56, as described in detail below. 
[0064] Wherever it is located, the database compo- 
nent 32 associated with the billing entity 56 stores biller- 
specific subscriber profile data, such as subscriber 
names and addresses and subscriber account numbers 
and types, e.g., business vs. residential phone line. The 
database component 32 also stores billing data for use 
by the user entity 52 In building the U! for the subscriber. 
The billing data can include bill availability data, detailed 
billing data, ads and other cross-sate displays and links, 
and bill payment terms and conditions. 
[0065] The database component 32 associated with 
the billing entity 56 can also store biller transaction his- 
tory, such as bill data manipulation, e.g., viewing, 
searching, and sorting, as well as cross-sell events. The 
database component 32 can further store biller profile 
data, such as graphics, business rules, and relation- 
ships with aggregators such as banks. 



[0066] The main function of the billing entity 56 is to 
provide billing data to the user entity 52 for use in cre- 
ating the Ul for the subscriber. The billing entity 56 also 
provides bill availability data to an aggregator database, 

5 whether it is located in the banking entity 54, the EPCS 
entity 58, or another entity, for use in providing notice of 
bill availability to subscribers. The billing entity 56 can 
also access legacy billing systems through the external 
message interface 36 of the billing entity 56, as Indicated 

10 above. 

[0067] Another function of the billing entity 56 is track- 
ing biller-related events and storing them in an even.t 
tracking database, which is typically associated with the 
EPCS entity 58, as described in detail below. 

15 

THE EPCS ENTITY 

[0068] The EPCS entity 58 can generally be de- 
scribed in terms of a data processing system 70, such 
20 as shown in Figure 5. The data processing system 70 
preferably includes at least one processor (P) 72, mem- 
ory (M) 74, and input/output (I/O) interface 76, which are 
connected to each other by a bus 78. for implementing 
the functions of the EPCS entity 58, as described in de- 
25 tail below. 

[0069] Referring again to Figure 4, the EPCS entity 
58 typically gains access to the system 50 through a net- 
work server (not shown). Thus, the database compo- 
nent 32 associated with the EPCS entity 58 can be lo- 
30 cated in the networi< server. However, if desired, the da- 
tabase component 32 associated with the EPCS entity 
58 can also be located in a system associated with the 
EPCS entity 58, such as a legacy aggregating system, 
or in one or among all of the other distributed database 
35 entities. Such a legacy aggregating system could be ac- 
cessed through the extemal message interface 36 of the 
EPCS entity 58, as described in detail below. 
[0070] Wherever it is located, the database compo- 
nent 32 associated with the EPCS entity 58 stores bill 
40 payment-specific subscriber profile data, such as sub- 
scriber names and addresses, subscriber DDA account 
numbers, and subscriber credit ratings. The database 
component 32 also stores bill payment warehouse data, 
such as user-specific payees, single occurrence pay- 
45 ments, and recurring payments/models. 

[0071] As previously described, both the banking en- 
tity 54 and the billing entity 56 track and store events in 
an event tracking database. This event tracking data- 
base is typically located in the database component 32 
50 associated with the EPCS entity 58. and typically in- 
cludes event summaries and links to other databases, 
perhaps residing at other entities, which provide event 
details and/or an audit trail. 

[0072] The database component 32 associated with 
55 the EPCS entity 58 also stores bill payment transaction 
histories, and system subscriber profile data, such as 
metadata about subscribers and metadata about sub- 
scribers' relationships to other entities, e.g., a list of bill- 
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ers that a subscriber has enabled. The database com- 
ponent 32 further stores billing-related profile informa- 
tion on the system aggregator and billers, such as meta- 
data about billing anrangements, e.g., flat rate, per sub- 
scriber, event-driven, etc., and aggregation data, such 
as new bill availability and messages or special an- 
nouncements available from the billing entity 56. The 
database component 32 associated with the EPCS en- 
tity 58 may additionally store security data, such as re- 
quired sign-on infonnation and macro-level authoriza- 
tions, and customer service data, such as frequently 
asked questions (FAQ's). Fl and biller contact infonna- 
tion, and problem resolution data. 
[0073] The EPCS entity 58 is the entity which ties the 
distributed database entities together. The EPCS entity 
58 accomplishes this by functioning as an integration 
agent which maintains bill payment profiles and ware- 
house data, aggregates bill availability and status data, 
but not bill content or presentation, and maintains an 
event tracking database, i.e. an audit trail, that can be 
accessed by all of the database entities. Also, in order 
to facilitate a single point of sign-on, the EPCS entity 58 
functions as the authentication gate keeper. This is not 
intended to imply that the EPCS entity 58 necessarily 
maintains user identification numbers and/or pass- 
words. However, it does mean that the EPCS entity 58 
accepts sign-on requests and doles out authentication 
"tickets" in response thereto, in conjunction with the 
banking entity as described above. 
[0074] Like user identification numbers and pass- 
words, other dataelements, such as event details, may 
be aggregated at the EPCS entity 58, but may still phys- 
ically reside in a distributed manner across several of 
the database entities. The EPCS entity 58 may also 
route e-mail messages to and from the variou s database 
entities, as well as store e-mail messages sent to and 
from the various database entities. 

INTERNAL MESSAGE PROCESSING 

[0075] The following types of messages are examples 
of messages which may be employed to implement an 
internal message interface 34 in accordance with the 
present invention. The message specification or file for- 
mat can be either standard, i.e., open, or special, i.e. 
proprietary. 

USER ENTITY INTERNAL MESSAGE PROCESSING 

[0076] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process an internal message to store a security 
ticket for later use in gaining access to other distributed 
database entities in the system 50, and/or to update any 
resident software. The user entity 52 may also need to 
process an internal message containing various types 
of information (assuming a push model), and/or internal 



e-mail messages, such as those for receiving data from 
other database entities. 

BANKING ENTITY, INTERNAL MESSAGE 
5 PROCESSING 

[0077] The banking entity 54 will process an Internal 
message to add/update/delete/retrieve Fl branding in- 
formation, and to add/update/delete an entry from a list 

10 of billers that have been aggregated. The banking entity 
54 will also process an internal message to activate a 
subscriber for home banking via a messaging protocol, 
which can be an existing messaging protocol, such as 
OFX, or a batch process, and to query/update bank sub- 

15 scriber profile data for purposes of customer care. The 
banking entity 54 will further process an internal mes- 
sage to query banktransaction history for customer care 
and for linking to the event tracking database, and to 
retrieve a list of billers available under the Fl sponsor 

20 umbrella or to place the list of billers available under the 
Fl sponsor umbrella in an aggregation database. Plac- 
ing the list of billers available under the Fl sponsor um- 
brella allows the EPCS entity 58 to tailor the list by Fl 
sponsor. 

25 [0078] The banking entity 54 will additionally process 
internal e-mail messages such as thosefor sending data 
to other database entitles, receiving data from other da- 
tabase entities, and broadcasting data to other data- 
base entities. 

30 

BILLING ENTfTY INTERNAL MESSAGE 
PROCESSING 

[0079] The billing entity 56 will process an internal 
35 message to add/update/delete/retrieve biller branding 
information, and to activate a subscriber for electronic 
bill presentment via a messaging protocol, which can be 
an existing messaging protocol, for example OFX, or a 
batch process. The billing entity 56 will also process an 
40 internal message to retrieve bill availability data, retrieve 
bill detail data, and retrieve bill presentation specifica- 
tions or content. The retrieved data could, for example, 
be URL links to ads and notices, HTML data, or OFX 
data. 

45 [0080] The billing entity 56 will also process an inter- 
nal message to query/update biller s ubscribe r p rof lie da- 
ta for purposes of customer care, and to query biller 
transaction history for customer care and for linking to 
the event tracking database. The billing entity 56 will ad- 

50 ditionally process internal e-mai! messages, such as 
those for sending data to other database entities, receiv- 
ing data from other database entities, and broadcasting 
data to other database entities. 

55 EPCS INTERNAL MESSAGE PROCESSING 

[0081] The EPCS entity 58 will process intemal event 
tracking messages used to gain access to two types of 
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information in the event tracking database: summary 
data and a link to another database entry that can pro- 
vide more detail, such as subscriber enrollment data, 
subscriber service activation data, e.g., biller, bill pay- 
ment, banking, etc., sign-on data, bill availability data, 
bill viewed data, bill payment generated data which is 
optionally associated with presented bill data, subse- 
quent bill payment events data, e.g., submitted, proc- 
essed, failed, cleared, remittance received by biller, etc., 
cross-sell events data, e.g., ad/offer viewed, ad/offer 
clicked, product/service purchased, temris & conditions 
viewed data, and e-mail created/read/deleted data. 
[0082] The EPCS entity 58 will also process internal 
messages related to subscriber profile data, such as to 
add/modify/delete/read subscriber profile data, often as 
a function of the events listed above, e.g., enrollment, 
activation, etc. 

[0083] The EPCS entity 58 will additionally process 
internal security messages. Such internal security mes- 
sages may relate to authentication, which result in the 
EPCS entity 58 issuing a security ticket. It should be not- 
ed that an authentication request does not have to be 
received as a result of a subscriber directly contacting 
the banking entity 54, but may be initiated if a subscriber 
attempts to gain access to the billing entity 56, without 
contacting the banking entity 54. The point being that 
with a security ticket a subscriber is generally allowed 
to freely traverse any database entity in the system 50 
without going through repeated sign-on procedures. 
[0084] An internal security message may relate to 
macro-level authorization, resulting in Issuance of a se- 
curity ticket that includes credentials allowing a sub- 
scriber access to a particular billing entity, without ad- 
dressing micro-level authorization issues such as the 
operations the subscriber will be allowed to perfomi. 
[0085] An internal security message may also result 
in issuance of a security ticket without authentication. 
Such a message will originate from a trusted party, e.g., 
an Fl perfomning its own authentication. 
[0086] It should be noted that the use of a security 
ticket enables, but does not mandate, a single sign-on 
procedure. In other words, a database entity, such as 
the billing entity 56, may, for whatever reason, require 
additional authentication information. 
[0087] The EPCS entity 58 will further process inter- 
nal messages relating to aggregation data. For exam- 
ple, an EPCS entity 58 will process an internal message 
to create a link to summary or detailed bill information, 
or to create a link to message, notice, ad, or some other 
kind of non-bill infomnation that is available from the bill- 
ing entity 56. 

[0088] Furthemnore, the EPCS entity 58 will process 
an internal message to query/update bill payment trans- 
action history for purposes of customer care. The EPCS 
entity 58 will process internal e-mail messages, such as 
those associated with routing e-mail, picking-up e-mail, 
and querying an e-mail mailbox. The EPCS entity 58 
may also process internal messages related to data 



mining. Such messages are handled very carefully to 
ensure privacy, perhaps even providing an ACL or other 
mechanisms to ensure privacy. The results of such mes- 
sages may be delivered out of band, e.g., by batch. 

5 

EXTERNAL MESSAGE PROCESSING 

[0089] Refen^ing to Figure 6, there is shown a sche- 
matic diagram of the versatile electronic bill present- 

10 ment and payment system 50, along with certain asso- 
ciated directly related systems. The directly related sys- 
tems includes a desktop database 80, a DDA system 
82, a legacy billing system 84, and a legacy remittance 
system 86. The communications between the various 

15 database entities and their associated directly related 
systems are perfomried over interconnections 88, which 
can be wire, optical fiber, or wireless based interconnec- 
tions. The message specification or file fomnat can be 
either standard, i.e., open, or special, i.e. proprietary. 

20 

USER ENTITY. EXTERNAL MESSAGE PROCESSING 

[0090] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 

25 browser client, or a Java client, the user entity 52 may 
need to process an external message in order to com- 
municate with a related system, such as the desktop da- 
tabase 80. To support a system, it may be necessary to 
Implement the external message interface 36 of the user 

30 entity 52 using an existing, and possibly extended, pro- 
tocol specification, such as Gold. NPC, or OFX, as will 
be understood by those skilled in the art. 

BANKING ENTITY EXTERNAL MESSAGE 
35 PROCESSING 

[0091] The banking entity 54 will process external 
messages to and from a related system, such as the 
DDA system 82, in order to query and update informa- 
40 tion, for example subscriber profile data, subscriber ac- 
count data, out-of-band (e.g., ATM) account activity and 
statement history. It may also be desirable for the bank- 
ing entity 54 to interface with other banking systems (e. 
g.p stops). 

45 

BILLING ENTITY EXTERNAL MESSAGE 
PROCESSING 

[0092] The billing entity 56 will process external mes- 
50 sages to and from related systems, such as the legacy 
billing system 84, in order to query and update informa- 
tion, for example subscriber profile data, subscriber ac- 
count data, account activity and statement history. Most 
of this data is industry, if not biller, specific. 

55 

EPCS EXTERNAL MESSAGE PROCESSING 
[0093] The EPCS entity 58 will process extemal mes- 
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sages to and from related systems, such as the legacy 
remittance system 86. The legacy remittance system 86 
could, for example, be an ACH. RPP. RPS, or Direct 
Send, as will be well understood by those skilled in the 
art. 

PARTNER MESSAGE PROCESSING 

[0094] Referring to Figure 7, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with some associ- 
ated indirectly related systems. The indirectly related 
systems Includes a personal finance system 90, a bank- 
ing system 92, an established billing aggregator 94, and 
an alternative bill presentment and payment system 96. 
The communications between the various database en- 
tities and the indirectly related systems are perfomned 
over interconnections 98, which can be wire, optical fib- 
er, or wireless interconnections. The message specifi- 
cation or file fomnat can be either standard, i.e., open, 
or special, i.e. proprietary. 

USER ENTITY PARTNER MESSAGE PROCESSING 

[0095] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
browser client, or a Java client, the user entity 52 may 
need to process a partner message in order to commu- 
nicate with a partner, such as the personal finance sys- 
tem 90. The personal finance system 90 could, for ex- 
ample, be a personal financial manager (PFM) software 
package such as Quicken (TM) or Money (TM). 

BANKING ENTITY PARTNER MESSAGE 
PROCESSING 

[0096] The banking entity 54 will process partner 
messages to and from a partner, such as the banking 
system 92. 

BILLING ENTITY PARTNER MESSAGE 
PROCESSING 

[0097] The billing entity 56 will process partner mes- 
sages to and from a partner, such as the established 
billing aggregator 94. Such a partner relationship may 
be required if a large group of subscribers are using the 
established billing aggregator 94, and thereby have the 
leverage to demand that all of their bills be communicat- 
ed through the established billing aggregator 94. 
[0098] The established billing aggregator 94 is essen- 
tially treated as a proxy for the billers that it represents. 
Thus, subscribers to the system 50 through the estab- 
lished billing aggregator 94 are treated in the same man- 
ner as direct subscribers to the system 50. This means 
that subscribers to the established billing aggregator 94 
will receive the same event tracking, customer service, 
and payment processing functionality as direct sub- 



scribers to system 50. 

[0099] To present a bill generated by the established 
billing aggregator 94 the system 50 may, for example, 
receive bill availability data and the URL of a web server 

5 of the established billing aggregator 94. The billing entity 
56 stores detailed bill data on the web server of the es- 
tablished billing aggregator 94 so that subscribers may 
obtain an l-TTML presentation of detailed bill data from 
the aggregator bill server. In this scenario, the partner 

10 message interface 38 would be essentially the same as 
an internal message interface 34, but could. If desired, 
have added bulk transfer capability. 

EPCS PARTNER MESSAGE PROCESSING 

15 

[0100] The EPCS entity 58 will process partner mes- 
sages to and from a partner, such as the altemative bill 
presentment and payment system 96. Such a partner 
relationship may be required if a billing entity 56 has a 

20 subscriber base that Includes both subscribers to the 
system 50 and subscribers to the alternative bill present- 
ment and payment system 96. 
[0101] In such a case, the system 50 could function 
as a billing aggregator for the altemative bill present- 

25 ment and payment system 96, or vice-versa. The alter- 
native bill presentment and payment system 96 and its 
subscribers might not receive any of the benefits of the 
messaging functionality provided by the present system 
50. Only limited functionality might be provided. That is, 

30 the partner message Interface 38 might only provide the 
functionally required to present bills through the alter- 
native bill presentment and payment system 96. As will 
be recognized by those skilled in the art, the EPCS entity 
58 will typically require capabilities of a billing entity 56 

35 in order to present bills to and from the alternative bill 
presentment and payment system 96. 

CUSTOMER CARE MESSAGE PROCESSING 

40 [0102] Referring to Figure 8, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with certain asso- 
ciated customer care entities. The customer care enti- 
ties include a user entity self sen^ice center 1 00, a bank- 

45 ing entity customer service center 102, a billing entity 
customer service center 104, and an EPCS customer 
service center 106. The communications between the 
various database entities and their associated customer 
care entities are perfomned over interconnections 108. 

50 which can be wire, optical fiber, or wireless interconnec- 
tions. The message specification or file format can be 
either standard, i.e., open, or special, i.e. proprietary. 

USER ENTITY CUSTOMER CARE MESSAGE 
55 PROCESSING 

[0103] Depending upon the nature of the presentation 
technology being used, e.g., a "fat" client, an HTML 
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browser client, or a Java client, the user entity 52 may 
need to process a customer care message in order to 
communicate with a customer care entity, such as the 
user entity self service center 100. The user entity self 
service center 100 could, for example, be a self service 
diagnostic tool. 

BANKING ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[0104] The banking entity 54 will process customer 
care messages from a customer care entity, such as the 
banking entity customer service center 1 02. A customer 
care message may be a request for data or a request to 
modify existing data. Such customer care messages are 
processed by providing the requested data or providing 
a confimnation that the existing data has been modified 
to the banking entity customer service center 1 02. The 
banking entity customer service center 102 could, for 
example, be a third party telemarketing group that is al- 
lowed access to banking and overall system data In or- 
der to provide feedback to system subscribers. 

BILLING ENTITY CUSTOMER CARE MESSAGE 
PROCESSING 

[01 05] The billing entity 56 will process customer care 
messages from a customer care entity, such as the bill- 
ing entity customer service center 1 04. A customer care 
message may be a request for data or a request to mod- 
ify existing data. Such messages are processed by pro- 
viding the requested data or providing a confirmation 
that the existing data has been modified to the billing 
entity customer service center 104. The billing entity 
customer service center 104 could, for example, be a 
third party telemarketing group that is allowed access to 
billing and overall system data in order to provide feed- 
back to system subscribers. 

EPCS CUSTOMER CARE MESSAGE PROCESSING 

[0106] The EPCS entity58will process customer care 
messages from a customer care entity, such as the 
EPCS entity customer service center 106. A customer 
care message may be a request for data or a request to 
modify existing data. Such messages are processed by 
providing the requested data or providing a confirmation 
that the existing data has been modified to the EPCS 
entity customer service center 1 06. The EPCS entity 
customer service center 1 06 could, for example, be a 
third party telemarketing group that is allowed access to 
event and overall system data in order to provide feed- 
back to system subscribers. 

[0107] It should be noted that all of the customer care 
entities described above could, if desired, be consoli- 
dated into a centralized customer service center 11 0, as 
shown In Figure 9. In such a case, each of the database 
entities would process customer care messages to and 



from the centralized customer service center 110 in a 
manner similar to that described above. Communica- 
tions between the various database entities and the cen- 
tralized customer service center 110 would be per- 
5 formed over interconnections 112, which may be wire, 
optical fiber, or wireless interconnections. 

MESSAGE FLOW 

10 [0108] Referring to Figures 10-15, there are shown 
flowchart diagrams of data and message flows between 
the various entities within the system 50. These flow-, 
chart diagrams assume that the user entity 52 is an 
HTIWL browser client, the banking entity 54 is the prima- 

15 ry point of presence for a subscriber to the system 50, 
the billing entity 56 controls bill presentment, and the 
EPCS entity 58 controls bill payment. 
[0109] In Figure 10, a subscriber at the user entity 52 
accesses the web site of the banking entity 54 in step 

20 200. In return, the banking entity 54 presents a branded 
interface to the user entity 52, including a sign-on re- 
quest prompt in step 202. Figure 16 shows an example 
of such a branded interface 120, wherein the sign-on 
request prompt includes a username field 122 and a 

25 password field 124. 

[0110] In Figure 11 , the user entity 52 submits a sign- 
on request with authentication credentials in steps 204. 
The banking entity 54 messages the EPCS entity 58 
with the authentication credentials of the subscriber and 

30 the event is logged in step 206. The EPCS entity 58 pro- 
vides a security ticket to the banking entity 54 in step 
208. The banking entity 54 delivers the security ticket to 
the user entity 52 and presents its "home page" to user 
entity 52 in step 210. Figure 17 shows an example of 

35 such a home page 1 30, which includes a "view bills" icon 
132, a 'View checking account" icon 134, and a "view 
savings account" icon 136. 

[0111] It should be noted that either the EPCS entity 
58 or the banking entity 54 could perfomn the authenti- 
40 cation procedure. In either case the event is logged in 
the event tracking database. 

[0112] In Figure 12. the subscriber selects the "view 
bills" icon 132 in step 212. The banking entity 54 mes- 
sages the EPCS entity 58 with an aggregation data re- 
45 quest and the event is logged in step 214. The EPCS 
entity 58 presents aggregation data of bill availability to 
user entity 52 in step 216. 

[0113] Figure 18 shows a modified home page 140 
having an EPCS entity frame 142 presenting the bill 

50 availability data, which Includes an "electric bill" Icon 
144, a "gas bill" icon 146, a "phone bill" icon 148, a "ca- 
ble bill" icon 1 50, a "credit card bill" icon 1 52, and an "all 
bills'* icon 154 which allows all bills to be presented si- 
multaneously, albeit in separate frames. 

55 [01 1 4] In Figure 1 3A, the subscriber selects the "gas 
bill" icon 146 and is linked to the billing entity 56. The 
security ticket is transmitted in step 218. The billing en- 
tity 56 messages the EPCS entity 58 to log the "view 
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bill" request event In step 220. The billing entity 56 
presents detailed bill data to the user entity 52 in step 
222. 

[0115] Figure 19 shows another modified home page 
160 having a billing entity frame 162 presenting the de- 
tailed bill data, which includes the subscriber name, sub- 
scriber address, account number, usage, and cost, and 
a "pay bill" icon 164. 

[0116] In Figure 14, the subscriber selects the "pay 
bill" icon 164 and messages the EPCS entity 58 with a 
fonward dated pay bill request. The event is logged in 
step 224. The EPCS entity 68 messages the billing en- 
tity 56 with a pay bill request notification along with a bill 
identification number in step 226. 
[0117] In Figure 15, the EPCS posts a debit with the 
banking entity 54, and the event is logged in step 228. 
The EPCS entity 58 then remits a payment to the billing 
entity 56 and the event is logged in step 230. 
[0118] Figure 13B can be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
if detailed bill data is provided by the established billing 
aggregator 94 thru the partner message interface 38 of 
the billing entity 56. As shown, the subscriber again se- 
lects the "gas bill" icon 146 and is linked to the billing 
entity 56. The security ticket is transmitted in step 232. 
The billing entity 56 again messages the EPCS entity 
58 to log the "view bill" request event in step 234. How- 
ever, in this case, detailed bill data is available only from 
the established billing aggregator 94. Thus, the billing 
entity 56 accesses the established billing aggregator 94 
through its partner message interface 38 in step 236. In 
response, the established billing aggregator 94 provides 
detailed bill data to the billing entity 56 in step 238. The 
billing entity 56 then presents the detailed bill data to the 
user entity 52 in step 240, 

[0119] It should be noted that, if desired, the estab- 
lished billing aggregator 94 could present the detailed 
bill data directly to the user entity 52. 
[0120] Figure 13C can be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
if detailed bill data is provided by the alternative bill pre- 
sentment and payment system 96 thru the partner mes- 
sage interface 38 of the EPCS entity 58, As shown, the 
subscriber selects the "gas bill" icon 146 and is linked 
back to the EPCS entity 58. The security ticket is trans- 
mitted and the event is logged in step 242. 
[0121] In this case, detailed bill data is available only 
from the alternative bill presentment and payment sys- 
tem 95. Thus, the EPCS entity 58 accesses the alterna- 
tive bill presentment and payment system 96 through its 
partner message interface 38 in step 244. In response, 
the alternative bill presentment and payment system 96 
provides detailed bill data to the EPCS entity 58 in step 
246. The EPCS entity 58 then presents the detailed bill 
data to the user entity 52 in step 248. 
[0122] Altematively, detailed bill data could, if desired, 
be provided by the alternative bill presentment and pay- 
ment system 96 thru the partner message interface 38 



of the billing entity 56 in a manner similar to that as de- 
scribed In Figure 13B. 

[0123] Refemng to Figure 20, there is shown a flow- 
chart diagram of data and message flows between the 

5 centralized customer service center 1 1 0 and the various 
entities within the system 50. A subscriber 170 contacts 
the centralized customer service center 110 regarding 
a bill payment in step 250. The centralized customer 
service center 110 accesses the event tracking data- 

10 base in the EPCS entity 58 to see if a view bill, pay bill, 
remit payment, or debit posting event has been logged 
in step 252. If more detailed information regarding, for 
example, the posting of a debit for a bill is required/the 
centralized customer service center 11 0 can access the 

15 database component 32 associated with the banking 
entity 54, as shown in step 254. Similarly, if more de- 
tailed information regarding, for example, the remitting 
of a payment for a bill is required, the centralized cus- 
tomer service center 1 1 0 can access the database com- 

20 ponent 32 associated with the billing entity 56, as shown 
in step 256, Although not shown, the EPCS entity 58 
can log all of the above-described accesses perfomned 
by centralized customer service center 110. 
[0124] As is apparent from the foregoing description, 

25 the system 50 allows a subscriber to interact directly 
with individual billers white retaining the benefits of in- 
teracting with a single aggregator, such as a single au- 
thentication and log-in procedure and a common bill 
presentation framework. The system 50 also allows a 

30 subscriber to interact with a single aggregator while al- 
lowing the billers and banks to retain control of subscrib- 
er-related data and a communication channel with each 
subscriber. 

[0125] The present invention is not to be limited in 
35 scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention 
in addition to those described herein, will be apparent 
to those of skill in the art such modifications are intended 
to fall within the scope of the appended claims. 

40 

Claims 

1 . A electronic bill presentment system, comprising: 

45 

a network; 

a plurality of first stations, each associated with 
a respective one of a plurality of users, opera- 
ble to transmit first requests for bills via the net- 
so work; 

a central network station configured to receive 
the transmitted first requests for bills and to 
transmit, responsive thereto, bill availability in- 
fomnation via the network, wherein the plurality 
55 of first stations are configure to receive the 

transmitted bill availability information and are 
operable to transmit second requests for bills 
via the networic; and 



11 



21 



EP1 136 922 A1 



22 



a plurality of second network stations, each as- 
sociated with a respective one of the plurality 
of billers, configured to receive the transmitted 
second requests for bills and to transmit, re- 
sponsive thereto, the requested bills via the 
network, 

2. ' A system according to claim 1 , wherein: 

each of the plurality of first stations is operable 
to transmit the first request for bills for its asso- 
ciated user; 

the central station is further configured to trans- 
mit, responsive to each of the received first re- 
quests, only the bill availability information for 
the user associated with that received first re- 
quest; 

each of the plurality of first stations is further 
configured to receive the transmitted bill avail- 
ability information for its associated user and is 
operable to transmit the second request for bills 
for Its associated user; and 
each of the plurality of second network stations 
is further configured to receive only the second 
requests for bills of its associated biller and to 
transmit, responsive to each of the received 
second requests, the bill of its associated biller 
for the user associated with that received sec- 
ond request. 

3. A system according to claim 2, wherein the bill avail- 
ability information for the associated user identifies 
those of the plurality of billers having an available 
bill for that user. 

4. A system according to claim 2, wherein the bill avail- 
ability information for the associated user identifies 
those of the plurality of billers having a bill available 
for that user without identifying an amount of the bill 
of each of the identified billers for the associated 
user. 

5. A system according to claim 1 , wherein: 



and 

the plurality of second stations includes a first 
biller station associated with the first biller and 
a second biller station associated with the sec- 
5 ond biller, the first biller station being further 

configured to receive the second requestforthe 
bill of the first biller and to transmit, responsive 
thereto, only the requested bill of the first biller 
for the first user, and the second biller station 
10 being further configured to receive the second 

request for the bill of the second biller and to 
transmit, responsive thereto, only the request-, 
ed bill of the second biller for the first user. 

15 6. A system according to claim 6, wherein: 

the first user station is further operable to se- 
lect both the identified bill of the first biller and iden- 
tified bill of the second biller, and to transmit the sec- 
ond request for the bill of the first biller and the sec- 

20 ond request for the bill of the second biller based 
upon the selection of both the bill of the first biller 
and the bill of the second biller. 

7. A system according to claim 1 , further comprising: 

25 

a first database configured to store the bill avail- 
ability infomnation; and 

a plurality of second databases, each config- 
ured to store those of the plurality of bills of a 
30 respective one of the plurality of billers; 

wherein the central network station Is further 
configured to transmit the bill availability infor- 
mation stored in the first database and each of 
the plurality of second network stations is fur- 
35 ther configured to transmit the requested bills 

of its associated biller stored in the respective 
one of the plurality of second databases storing 
the bills of that biller. 

40 8. A system according to claim 1 , wherein: 

the plurality of second network stations in- 
cludes a first biller station associated with a respec- 
tive one of the plurality of billers and other billers. 

9. A method for presenting electronic bills, comprising 
the steps of: 

storing, at a plurality of different locations, elec- 
tronic bills of a plurality of different billers for a 
plurality of different users; 
storing Identifiers of the stored electronic bills 
at a location different than the plurality of differ- 
ent locations; 

transmitting a first request for the stored elec- 
tronic bills for a first of the plurality of users; 
transmitting one or more of the stored identifi- 
ers of the stored electronic bills for the first user 
responsive to the transmitted first request, 



the plurality of users includes a first user; ^5 
the plurality of billers includes a first biller and 
a second biller; 

the bill availability infonmation for the first user 
identifies the first biller and the second biller; 
the plurality of first stations includes a first user so 
station associated with the first user which is 
operable to select one of the identified bill of the 
first biller and the identified bill of the second 
biller, and to transmit a second request for the 
bill of the first biller based upon the selection of ss 
the bill of the first biller and to transmit a second 
request for the bill of the second biller based 
upon the selection of the bill of the second biller; 
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each of the transmitted one or more identifiers 
being associated with a respective one of the 
stored electronic bills of a different one of the 
plurality of billers; 

transmitting a second request for at least one 
of the stored electronic bills identified by the 
transmitted one or more identifiers; and 
transmitting the at least one identified stored 
electronic bill responsive to the transmitted 
second request. 

10. A method according to claim 9, wherein the one or 
more stored identifiers is at least two stored identi- 
fiers, the at least one identified stored electronic bill 
Is two or more identified stored electronic bills, and 
further comprising the steps of: 

presenting the transmitted at least two stored 

identifiers to the first user; and 

separately presenting the transmitted two or 

more identified stored electronic bills to the first 

user. 

11. A method according to claim 9, wherein the trans- 
mitted one or more identifiers identifies the stored 
electronic bills without identifying an amount of the 
identified stored electronic bills. 

1 2. A method according to claim 9, 1 0 or 11 wherein the 
one or more stored identifiers are two stored iden- 
tifiers and further comprising the step of: . 

selecting one of the transmitted two identifiers; 
wherein the second request is for only the 
stored electronic bill identified by the selected 
identifier. 

13. A method according to claim 9. wherein the one or 
more stored identifiers are two stored identifiers and 
further comprising the step of; 

selecting all of the transmitted two identifiers; 
wherein the second request is for the stored 
electronic bills identified by the selected identi- 
fiers. 

14. A electronic bill presenter, comprising: 

a database configured to store bill availability 
information identifying available electronic bills 
of a plurality of different billers for a plurality of 
different users; and 

a processor configured (i) to receive, from a first 
of the plurality of different users, a first request 
for bills of the first user, (ii) to transmit, respon- 
sive thereto, the stored bill availability infomna- 
tion identifying the available electronic bills of 
the plurality of different billers, Including a first 
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bill of a first biller, for the first user, (ill) to re- 
ceive, from the first biller, a notification of a sec- 
ond request for the first bill, and (iv) to log the 
received notification. 

5 

15. An electronic bill presenter according to claim 14, 
wherein the bill availability information Identifies the 
first bill without identifying an amount of the first bill. 

10 16. An electronic bill presenter according to claim 14, 
wherein the processor is further configured to re- 
ceive, from the first user, a request to pay the first 
bill to the first biller, to log the received pay reqirest, 
and to transmit a notification of the pay request to 

15 the first biller. 

17. An article of manufacture for presenting bills elec- 
tronically, comprising: 

20 a computer readable storage medium; and 

computer programming stored on the medium 
and configured to be readable from the medium 
by a computer processor and thereby cause the 
processor to operate so as to: 

25 

process a first signal requesting electronic 
bills of a first of a plurality of different users; 
generate a second signal Identifying avail- 
able electronic bills of a plurality of different 

30 billers for the first user; 

transmit the second signal to the first user; 
process a third signal representing a notice 
of a request for the available electronic bills 
identified in the second signal; and 

35 log the third signal. 

18. An article of manufacture according to claim 17. 
wherein the computer programming is further con- 
figured to cause the processor to operate so as to: 

40 

process a fourth signal requesting payment of 
one of the available electronic bills identified in 
the second signal to a first of the plurality of dif- 
ferent billers; and 
45 transmit a notification of the pay request to the 

first biller. 

19. An article of manufacture according to claim 18, 
wherein the fourth signal is received from the first 

50 user. 

20. An article of manufacture according to claim 17, 
wherein the available electronic bills of the plurality 
of different billers identified in the second signal in- 

55 eludes a first bill of a first biller and the third signal 
is received from the first biller. 

21. An article of manufacture according to claim 17, 
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wherein the first signal is received fronn the first us- 
er. 
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